[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: weshayutin
Once this PR has been reviewed and has the lgtm label, please assign mateusoliveira43 for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

... or is ${OADP.Current} shipped to OCP version+1?

This probably isn't the best course given the shortcomings discovered with OADP 1.3 on OCP v4.16. If anything, "${OADP.Next} shipped to OCP version-1"

@weshayutin "Deprecation notice OADP-1.4 on OCP 4.19" -- I don't think deprecation is the right word, since "deprecated" means "still supported but will not be supported in the future", but 1.4 isn't supported at all, so I think we should just say "unsupported" rather than "deprecated".

@weshayutin "Deprecation notice OADP-1.4 on OCP 4.19" -- I don't think deprecation is the right word, since "deprecated" means "still supported but will not be supported in the future", but 1.4 isn't supported at all, so I think we should just say "unsupported" rather than "deprecated".

@sseago , In the current context, I believe, "deprecation" is an accurate term here and we further clarify in the deprecation message the expectation. This will likely forever be up for discussion in its use in given contexts. Regardless of the semantics argument, we'll need to use olm.deprecations to raise the message about being unsupported.

Perhaps clarify the intention of the point?

[ ] Deprecation notice of OADP 1.4 on OCP v4.19 being unsupported

example from olm.deprecations:

schema: olm.deprecations
package: deprecation-example
entries:
  - reference:
  	schema: olm.bundle
  	name: deprecation-example-operator.v1.68.0
    message: |
   	deprecation-example-operator.v1.68.0 is deprecated. Uninstall and install deprecation-example-operator.v1.72.0 for support.

Have the message content provide clarity on the position and provide guidance to the solution -- OADP 1.4 is unsupported. Upgrade to OADP 1.5

... or is ${OADP.Current} shipped to OCP version+1?

This probably isn't the best course given the shortcomings discovered with OADP 1.3 on OCP v4.16. If anything, "${OADP.Next} shipped to OCP version-1"

Discussions are in favor of migrating from SQLite catalogs to FBC, raising a message (via olm.deprecations) to reflect the installed unsupported version, and providing an in-channel upgrade path on the updated OCP version for OADP from a now-unsupported version to a supported version. The expectation is that OLM will roll through upgrading those deployed with an Automatic update approval for OADP; no different than any other release to channel like we have today. While those with Manual update approval will have to manually 😮 approve the update, we'll have the additional benefit of the deprecation message alerting them to the reason for the need to update; currently unsupported, upgrade to the next dot-Y release for continued support.

Worth mentioning... disruption to existing deployments is expected on OCP upgrades as OADP transitions to this and channel(s) are reworked to support this change. Users will need to switch to the yet-to-be-named channel allowing for this new desired update path.

We should strive to keep OADP on current OCP versions (<=v4.16?) consistent -- stable-1.0, stable-1.3, stable-1.4 -- while introducing a new (stable? stable-1?) channel going forward that supports the Y-version upgrades desired. Once implemented, existing installs would need to flip from current stable-1.4 to the new (stable-1?) channel that supports upgrading across the OADP 1.Y release boundary across OCP version upgrades. Setting this new (stable-1?) channel as the default channel will natively support this update path on new default installs of OADP.

💭 Is this being aligned with OADP 1.5 & OCP v4.19?

Worth mentioning... disruption to existing deployments is expected on OCP upgrades as OADP transitions to this and channel(s) are reworked to support this change. Users will need to switch to the yet-to-be-named channel allowing for this new desired update path.

We should strive to keep OADP on current OCP versions (<=v4.16?) consistent -- stable-1.0, stable-1.3, stable-1.4 -- while introducing a new (stable? stable-1?) channel going forward that supports the Y-version upgrades desired. Once implemented, existing installs would need to flip from current stable-1.4 to the new (stable-1?) channel that supports upgrading across the OADP 1.Y release boundary across OCP version upgrades. Setting this new (stable-1?) channel as the default channel will natively support this update path on new default installs of OADP.

💭 Is this being aligned with OADP 1.5 & OCP v4.19?

Yes, this will be aligned to OADP-1.5 && OCP 4.19. I'll add a name discussion to the description "stable" seems like right move. Customer would be required to flip from stable-1.4 to stable to get to OADP-1.5. IMHO no channel name will be fully descriptive to all customers, will require doc.

@weshayutin: all tests passed!

Full PR test history. Your PR dashboard.

IMHO no channel name will be fully descriptive to all customers, will require doc.

Agreed.
For OADP, that would continue to leverage stable in some variation.
We should continue to use channel names that are documented/recommended. I expect, even if the doc table isn't updated to include it, the eus prefix is common/understrood given OCP's use of it.

I suppose that might be one to consider as discussions happen around channels in relation to the longer-lived EUS and potential requirement to backport in support of the same. Although, it could be argued to eventually only have a single stable channel and only promote the correct versions for the particular OCP version.

We need to be cognizant of the update graph(s) we're creating.

Using an appropriate combination of olm.skipRange, skips, & replaces, in the v4.18 to v4.19 upgrade we should be able to support updating from 1.4.N to 1.5.0 (and then continuing along the 1.5.Z updates). For simplicity, we could manage consistently the, for example, 1.5 channel to be identical -- or, it could be separate such that there is no update path for 1.4 to 1.5 on v4.20 where one does exist on v4.19. In the instance of supporting EUS to EUS (v4.16 -> v4.18) upgrades, we'd want to keep consistent -- or, at least, ensure we support the EUS to EUS path.

💭 Are OCP upgrades supported from EUS to EUS directly? v4.16 -> v4.18? or still require v4.16 -> v4.17 -> v4.18?
It seems so...

• eus-4.y (only offered for EUS versions and meant to facilitate updates between EUS versions)